Lost in the Middle論文
https://scrapbox.io/files/65b881273588c70024179adb.png
論文情報
タイトル：Lost in the Middle: How Language Models Use Long Contexts
発行日：2023年7月
著者：Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang
所属：Stanford University
論文を読んで感じたこと
プロンプトの解説書にはできるかぎり詳細な説明をつけるとある。
しかし、言語モデルにより多くの情報を提供することは、モデルが推論する必要があるコンテンツの量も増加し、精度が低下する可能性がある。
言語モデルのパフォーマンスは、関連情報が入力コンテキストの最初または最後にあるときが最も高く、モデルが入力コンテキストの中間で情報にアクセスして使用する場合、パフォーマンスは大きく低下する
https://scrapbox.io/files/65abe1c534b62e0022df9b79.png
U字型の曲線は、心理学において系列位置効果(シリアルポジション効果)として知られている
一般的に、始めの方(初頭効果)と最後の方(親近効果)に学習したものが、途中で学習したものよりも記憶に残りやすいと言われている。
プレゼンなども最初と最後が印象に残りやすい。
シリアルポジション効果は、人間が短期および長期記憶をどのように発達させるかを理解する上での役割を果たすと言われているが、これがLLMにも当てはまるのがとても興味深い
GPT-4のリコール性能は73Kトークンを超えると低下し始める
低いリコール性能は、リコールされるファクトが文書の深さ7％～50％の間に配置された場合に相関する
ファクトが文書の先頭にある場合、コンテキストの長さに関係なくリコールされる。
https://scrapbox.io/files/65abec63c8311b0024c06c65.png
https://www.youtube.com/watch?v=KwRRuiCCdmc
チャンクが多い≠優れているわけではない
概要
最近の言語モデルは長いコンテキストを入力として受け取る能力を持っていますが、これらがどの程度効果的に長いコンテキストを使用しているかについては、あまり知られていません。我々は、言語モデルが入力コンテキスト内の関連情報を特定する必要がある二つのタスク（多文書の質問応答とキー値の取得）におけるパフォーマンスを分析しました。関連情報の位置を変えるとパフォーマンスが著しく低下することが分かり、現在の言語モデルが長い入力コンテキスト内の情報を堅固に活用していないことを示唆しています。特に、関連情報が入力コンテキストの始まりや終わりにある場合のパフォーマンスが最も高く、長いコンテキストの中間に関連情報にアクセスする必要がある場合、明示的に長いコンテキストのモデルであっても、パフォーマンスは著しく低下することが観察されました。我々の分析は、言語モデルが入力コンテキストをどのように使用するかについての理解を深め、将来の長いコンテキストの言語モデルのための新しい評価プロトコルを提供します。
1 はじめに
言語モデルは、会話インターフェース、検索と要約、共同執筆など、多様なユーザー対面の言語技術において重要かつ柔軟な構成要素となっています。これらのモデルは、主にプロンプトによって下流タスクを実行します：すべての関連するタスク仕様と処理するデータはテキスト入力コンテキストとしてフォーマットされ、モデルは生成されたテキストを返します。これらの入力コンテキストは、特に言語モデルが長文書（例えば、法的または科学的文書、会話履歴など）を処理する際や、外部情報（例えば、検索エンジンからの関連文書、データベースのクエリ結果など）で拡張された場合には、数千のトークンを含むことがあります。
これらの用途を扱うには、言語モデルが長いシーケンスを効果的に操作する必要があります。既存の言語モデルは一般的にTransformerで実装されており、シーケンス長が増加するとメモリと計算量が二次的に増加します。その結果、トランスフォーマー言語モデルは比較的小さいコンテキストウィンドウ（512〜2048トークンの間）で訓練されていました。ハードウェアの改善（例えば、より多くのメモリを持つ高速GPU）やアルゴリズムの進歩により、より大きなコンテキストウィンドウ（例えば、4096、32K、さらには100Kトークン）を持つ言語モデルが登場しましたが、これらの拡張コンテキスト言語モデルが、下流タスクを実行する際に入力コンテキストをどのように使用しているかは明確ではありません。 我々は、入力コンテキストのサイズと関連情報の位置をコントロールする実験を通じて、この問いに対する実証的な調査を行いました。言語モデルが長い入力コンテキスト内の情報を堅固に使用できる場合、関連情報の位置によってパフォーマンスに最小限の影響しか与えられないはずです。
まず、我々は多文書の質問応答に関する実験を行いました。このタスクでは、モデルが提供された文書の中から関連情報を見つけ、それを使って与えられた質問に答える必要があります。このタスクは、多くの商業的な生成型検索や質問応答アプリケーション（例えば、Bing Chat）の基盤となる情報取得強化生成のセットアップを模倣しています。この設定では、(i) 入力コンテキストの文書数を変更することで入力コンテキストの長さを制御し（情報取得強化生成でより多くまたは少なく文書を取得するのと同様に）、(ii) 文書の順序を変更して関連文書をコンテキストの始まり、中間、または終わりに配置することで、入力コンテキスト内の関連情報の位置を制御します。
我々は、入力コンテキスト内の関連情報の位置を変更することがモデルのパフォーマンスに大きく影響を与えることを発見しました。これは、現在の言語モデルが長い入力コンテキスト内の情報に堅固にアクセスし、使用していないことを示唆しています。さらに、我々は特徴的なU字型のパフォーマンス曲線（Figure 1）を観察しました。
https://scrapbox.io/files/65ab9c1015cef700228c1772.png
言語モデルのパフォーマンスは、関連情報が入力コンテキストの最初（プライマシー効果）または最後（リセンシー効果）にあるときが最も高く、モデルが入力コンテキストの中間で情報にアクセスして使用する必要がある場合、パフォーマンスは大幅に低下します（§2.3）。例えば、関連情報が入力コンテキストの中間に配置された場合、GPT-3.5-Turboの多文書の質問応答タスクのパフォーマンスは、文書が一切ない（つまり、クローズドブック設定）場合のパフォーマンスよりも低くなります（56.1%）。さらに、モデルのパフォーマンスがその拡張コンテキストの対応物と同じであることが多いこともわかり、これは拡張コンテキストモデルが必ずしも入力コンテキストをよりよく使用するわけではないことを示しています（§2.3）。 言語モデルが多文書の質問応答タスクで関連情報を取得し、使用するのに苦労していることを考えると、言語モデルは入力コンテキストからどの程度情報を取得できるのでしょうか？我々はこの疑問を、入力コンテキストから一致するトークンを取得する基本的な能力を最小限のテストベッドとして設計された合成キー値取得タスクで研究しました。このタスクでは、モデルにJSON形式のキー値ペアのコレクションが与えられ、特定のキーに関連付けられた値を返す必要があります。多文書QAタスクと同様に、キー値取得タスクでは入力コンテキストの長さ（より多くのキー値ペアを追加する）と関連情報の位置への制御された変更が可能です。いくつかのモデルは合成キー値取得タスクを完璧に実行しますが、他のモデルは入力コンテキストの中間にある一致するトークンを単純に取得することに苦労し、U字型のパフォーマンス曲線を続けて示します。
言語モデルが入力コンテキスト内の情報に堅固にアクセスし、使用するのに苦労する理由をより深く理解するために、我々はモデルアーキテクチャ（デコーダのみ対エンコーダ・デコーダ）、クエリ認識のコンテキスト化、および指示のファインチューニングの役割を研究しました（§4）。我々は以下のことを発見しました： エンコーダ・デコーダモデルは、訓練時のシーケンス長内で評価される場合、入力コンテキスト内の関連情報の位置の変化に比較的堅固です。しかし、訓練中に見られるシーケンスより長いシーケンスで評価される場合、我々はU字型のパフォーマンス曲線を観察します（§4.1）。
クエリ認識のコンテキスト化（クエリを文書やキー値ペアの前後に配置する）は、合成キー値タスクでほぼ完璧なパフォーマンスを可能にしますが、多文書QAの傾向にはほとんど変化をもたらしません（§4.2）。
ベースの言語モデル（つまり、指示のファインチューニングなし）でも、入力コンテキスト内の関連情報の位置を変えるとU字型のパフォーマンス曲線が見られます。
我々の結果は、言語モデルにより長い入力コンテキストをプロンプトすることはトレードオフであることを示しています。言語モデルにより多くの情報を提供することは、下流タスクの実行に役立つかもしれませんが、モデルが理由づけを行う必要があるコンテンツの量も増加し、精度が低下する可能性があります。このトレードオフを実際に理解するために、我々はオープンドメインの質問応答におけるリトリーバーリーダーモデルをケーススタディとして実施しました（§5）。制御された多文書QAタスクとは対照的に、オープンドメインQA設定では、トップkの文書の中に答えが含まれているかもしれないし、含まれていないかもしれません。NaturalQuestions-Openの研究では、モデルのパフォーマンスがリトリーバーのリコールが飽和するよりずっと前に飽和することがわかりました。これは、現在のモデルが追加で取得した文書を効果的に使用できていないことを示しています。たとえば、20の文書の代わりに50の文書を使用しても、パフォーマンスはわずかに向上するだけです（GPT-3.5-Turboで約1.5%、claude-1.3で約1%）。 私たちの分析は、言語モデルが入力コンテキストをどのように使用するかについての理解を深め、将来の長いコンテキストのモデルに対する新しい評価プロトコルを導入します。言語モデルが長い入力コンテキスト内の情報を堅固に使用できると主張するためには、入力コンテキスト内の関連情報の位置によってパフォーマンスが最小限に影響を受けることを示す必要があります（例えば、最良と最悪のケースのパフォーマンスに最小の差）。
言語モデルが入力コンテキストをどのように使用するかを理解し、改善するためのさらなる作業を支援するために、私たちはコードと評価データを公開します。
2 多文書の質問応答
我々の目的は、言語モデルが入力コンテキストをどのように使用するかをより深く理解することです。この目的のために、我々は多文書の質問応答におけるモデルのパフォーマンスを分析します。このタスクでは、モデルは入力コンテキスト内の関連情報を見つけ、それを使って質問に答える必要があります。特に、我々は入力コンテキストの長さと関連情報の位置に制御された変更を加え、タスクパフォーマンスの変化を測定します。
2.1 実験セットアップ
多文書の質問応答タスクでは、モデルの入力は(i)答えるべき質問と(ii)k個の文書（例えば、Wikipediaからの抜粋）です。このうち、正確に1つの文書が質問への答えを含み、k-1個の「誤解を招く」文書は含まない。このタスクでは、モデルは入力コンテキスト内の答えを含む文書にアクセスし、それを使って質問に答える必要があります。Figure 2に例を示します。
https://scrapbox.io/files/65ab9fc31123630024c36a9f.png
このタスクは、Google検索エンジンに対して行われた歴史的なクエリと、Wikipediaから抽出された人間による注釈付き回答を含むNaturalQuestions-Openのデータを使用して実装されています。特に、注釈付き長い回答が段落である（リストや表ではない）2655のクエリを取り上げています。我々は、Wikipediaの文書（最大100トークンのチャンク）を入力コンテキスト内の文書として使用します。
各クエリに対して、答えを含む文書とk-1の誤解を招く文書が必要です。質問に答える文書を得るために、我々はNaturalQuestionsの注釈から答えを含むWikipediaの段落を使用します。答えを含まないk-1の誤解を招く文書を集めるために、我々は検索システム（Contriever、MS-MARCOでファインチューニングされた; Izacard et al., 2021）を使用して、クエリに関連が最も高く、NaturalQuestionsで注釈付けられた答えを含まないk-1のWikipediaチャンクを取得します。入力コンテキスト内では、誤解を招く文書は関連性が減少する順に提示されます。
入力コンテキスト内の関連情報の位置を調整するために、答えを含む文書の位置を変更することで文書の順序を調整します（Figure 3）。
https://scrapbox.io/files/65aba045a298840023827885.png
このタスクで入力コンテキストの長さを調節するために、答えを含まない取得された文書の数を増やしたり減らしたりします（Figure 4）。
https://scrapbox.io/files/65aba098f3c30a0023c8cb14.png
Kandpal et al. (2022)とMallen et al. (2023)に従って、我々は主な評価指標としてAccuracyを使用し、NaturalQuestionsの注釈から取られた正解のいずれかが予測出力に現れるかどうかを判断します。我々の実験セットアップは、Ivgi et al. (2023)のneedle in a haystackの実験に似ており、関連する段落が(i)入力の最初に配置された場合と(ii)入力内のランダムな位置に配置された場合の質問応答パフォーマンスを比較します。彼らは、関連情報が入力コンテキストの最初に配置された場合、エンコーダ・デコーダモデルのパフォーマンスが著しく高いことを発見しました。対照的に、我々は関連情報の位置により詳細な変化を研究します。 2.2 モデル
我々は、最先端のオープンおよびクローズド言語モデルを複数分析します。出力を生成する際には貪欲なデコーディング戦略を使用し、他のデコード方法の探索は将来の研究に委ねます。各モデルには標準的なプロンプトセットを使用します（Figure 2参照）。オープンモデルとしては、8192トークンまでの最大コンテキスト長を持つMPT-30B-Instructを実験します。このモデルは当初、2048トークンのシーケンスを使用して1兆トークンで事前学習され、その後8192トークンのシーケンスを使用して50億トークンでの追加のシーケンス長適応事前学習フェーズを経ています。MPT-30B-InstructはALiBi（Press et al., 2022）を使用して位置情報を表現しています。また、16384トークンのシーケンスでファインチューニングする前に、凝縮されたロータリーポジショナル埋め込みを使用してLLaMA-13B（Touvron et al., 2023a）のコンテキストウィンドウを2048トークンから16384トークンに拡張したLongChat-13B（16K）（Li et al., 2023）も評価しています。 クローズドモデルとしては、OpenAI APIを使用してGPT-3.5-TurboとGPT-3.5-Turboを実験します。GPT-3.5-Turboは最大4Kトークンのコンテキスト長を持ち、GPT-3.5-Turbo（16K）は16Kトークンの拡張された最大コンテキスト長を持つバージョンです。Claude-1.3とClaude-1.3（100K）はAnthropic APIで評価されます。Claude-1.3は最大8Kトークンのコンテキスト長を持ち、Claude-1.3（100K）は100Kトークンの拡張されたコンテキスト長を持ちます。 2.3 結果と議論
我々は、10、20、30の合計文書を含む入力コンテキストで実験を行いました。図5は、入力コンテキスト内の関連情報の位置を変えることによる多文書の質問応答のパフォーマンスを示しています。モデルのパフォーマンスを文脈化するために、クローズドブック設定とオラクル設定でも評価を行います（表1参照）。クローズドブック設定では、モデルには入力コンテキスト内に文書が与えられず、正しい回答を生成するためにパラメトリックメモリに依存する必要があります。一方、オラクル設定では、言語モデルには答えを含む唯一の文書が与えられ、それを使用して質問に答える必要があります。
モデルのパフォーマンスは、関連情報が入力コンテキストの始まりまたは終わりにある場合に最も高くなります。Figure 5に示されているように、入力コンテキスト内の関連情報の位置を変えることによって、モデルのパフォーマンスは大幅に低下します。特に、我々は特徴的なU字型のパフォーマンス曲線を観察しました。モデルは、コンテキストの非常に始まり（プライマシー効果）と非常に終わり（リセンシー効果）に発生する関連情報を使用することが非常に得意ですが、入力コンテキストの中間にある情報を使用するよう強制された場合、パフォーマンスが低下します。例えば、GPT-3.5-Turboの多文書QAパフォーマンスは、最悪の場合、20文書と30文書の設定で、入力文書が一切ない場合（つまり、クローズドブックパフォーマンス；56.1%）よりも20%以上低下することがあります。これらの結果は、現在のモデルが下流タスクのために提示された際に、全体のコンテキストウィンドウを効果的に考慮することができないことを示しています。
https://scrapbox.io/files/65abc323099dfd0023487345.png
拡張コンテキストモデルが必ずしも入力コンテキストをよりよく使用するわけではありません。入力コンテキストがモデルとその拡張コンテキストの対応物の両方のコンテキストウィンドウに収まる場合、そのパフォーマンスはほぼ同一であることがわかります。例えば、10文書と20文書の設定はどちらもGPT-3.5-TurboとGPT-3.5-Turbo (16K)のコンテキストウィンドウに収まり、関連情報の位置に応じたパフォーマンスはほぼ重ね合わせられることが観察されます（図5の実線の紫色と破線の茶色のシリーズ）。これらの結果は、拡張コンテキストモデルがその入力コンテキストを使用する際に、非拡張の対応物よりも必ずしも優れているわけではないことを示しています。
3 言語モデルは入力コンテキストからどの程度情報を取得できるのか？
言語モデルが多文書の質問応答タスクで入力コンテキストの中間から情報を取得し使用するのに苦労していることを考えると、それらは入力コンテキストからどの程度単純に取得できるのでしょうか？我々はこの疑問を、入力コンテキストから一致するトークンを取得する基本的な能力を最小限のテストベッドとして設計された合成キー値取得タスクで研究します。
3.1 実験セットアップ
合成キー値取得タスクでは、入力は(i)k個のキー値ペアを含む文字列化されたJSONオブジェクトで、各キーと値は一意のランダム生成されたUUIDであり、(ii)前述のJSONオブジェクト内のキーです。目標は、指定されたキーに関連付けられた値を返すことです。したがって、各JSONオブジェクトには、返されるべき1つの関連キー値ペア（値）と、k-1の関連性のない「誤解を招く」キー値ペアが含まれます。Figure 6は、入力コンテキストとそれに対応する望ましい出力の例を示しています。我々は、予測された出力に正しい値が表示されるかどうかを評価することにより、正確性を再び測定します。
https://scrapbox.io/files/65abc6b5d4ce400024a05f9f.png
我々の合成キー値取得タスクは、Papailiopoulos et al. (2023)のLittle Retrieval TestやLi et al. (2023)の詳細な行取得タスクと同様の目的を共有していますが、自然言語のセマンティクスを可能な限り取り除くことにより、タスクを明確に蒸留し、単純化することを目指しています（ランダムUUIDを使用することで）。言語の特徴は潜在的な混乱要因を提示する可能性があるためです。たとえば、トランスフォーマー言語モデルは、入力に含まれる異なる言語的特徴に対して感度が異なる場合があります（O'Connor and Andreas, 2021）。
入力コンテキスト内の関連情報の位置を調整するために、シリアル化されたJSONオブジェクト内の取得するキーの位置を変更します。入力コンテキストの長さを調節するために、ランダムなキーを追加または削除することで入力JSONキー値ペアの数kを変更し、誤解を招くキー値ペアの数を変更します。
3.2 結果と議論
我々は、75、140、300のキー値ペアを含む入力コンテキストで実験を行いました（それぞれ500の例）。多文書の質問応答実験と同じモデルセットを使用します。詳細は§2.2を参照してください。
Figure 7は、キー値取得のパフォーマンスを示しています。Claude-1.3とClaude-1.3 (100K)は、評価されたすべての入力コンテキストの長さでほぼ完璧なパフォーマンスを達成していますが、他のモデルは特に140または300のキー値ペアを含むコンテキストで苦労しています。合成キー値取得タスクは、入力コンテキスト内で正確な一致を特定するだけが必要ですが、すべてのモデルが高いパフォーマンスを達成するわけではありません。多文書QAの結果と同様に、GPT-3.5-Turbo、GPT-3.5-Turbo (16K)、およびMPT-30B-Instructは、入力コンテキストの中間にあるキー値ペアにアクセスする必要がある場合に最も低いパフォーマンスを示しています。LongChat-13B (16K)は、140のキー値設定で異なる傾向を示しています。我々は定性的に観察しましたが、関連情報が入力コンテキストの最初に配置された場合、LongChat-13B (16K)は値を直接出力するのではなく、キーを取得するためのコードを生成する傾向があります。
https://scrapbox.io/files/65abcb5056fd6d002568ea28.png
4 言語モデルが関連情報の位置の変更に対して堅固でない理由
我々の多文書質問応答とキー値取得の結果は、言語モデルが長い入力コンテキスト内の情報に堅固にアクセスし、使用するのに苦労していることを示しています。これは、関連情報の位置を変更するとパフォーマンスが著しく低下するためです。その理由をより深く理解するために、モデルアーキテクチャ（デコーダーのみ対エンコーダー・デコーダー）、クエリ認識のコンテキスト化、指示のファインチューニングの役割についていくつかの予備的な調査を行いました。
4.1 モデルアーキテクチャの影響
我々が評価したオープンモデルはすべてデコーダーのみのモデルです。つまり、各タイムステップで前のトークンのみに注意を払います。言語モデルがコンテキストをどのように使用するかにモデルアーキテクチャがどのような影響を与えるかをより深く理解するために、デコーダーのみとエンコーダー・デコーダーの言語モデルを比較します。
Flan-T5-XXL（Raffel et al., 2020; Chung et al., 2022）とFlan-UL2（Tay et al., 2023）を実験に使用しました。Flan-T5-XXLは512トークンのシーケンス（エンコーダーおよびデコーダー）で訓練されています。Flan-UL2は初期に512トークンのシーケンス（エンコーダーおよびデコーダー）で訓練された後、1024トークン（エンコーダーおよびデコーダー）で追加の100Kステップを事前学習し、2048トークンのエンコーダーと512トークンのデコーダーで指示のファインチューニングを行います。これらのモデルは相対的な位置埋め込みを使用するため、原理的にはこれらの最大コンテキスト長を超えて外挿することができます。Shaham et al.（2023）によると、どちらのモデルも8Kトークンまでのシーケンスでうまく機能することがわかっています。
Figure 8は、デコーダーのみとエンコーダー・デコーダーモデルのパフォーマンスを比較しています。Flan-UL2が2048トークンの訓練時のコンテキストウィンドウ内で評価された場合（図8の左サブプロット）、入力コンテキスト内の関連情報の位置の変化に対してそのパフォーマンスは比較的堅固です（最良と最悪のケースのパフォーマンスの絶対差は1.9%）。2048トークンを超えるシーケンスの設定で評価された場合（図8の中央と右）、Flan-UL2のパフォーマンスは、関連情報が中央に配置された場合に低下し始めます。Flan-T5-XXLも同様の傾向を示し、より長い入力コンテキストでは、入力コンテキストの中央に関連情報を配置するとパフォーマンスの低下が大きくなります。我々は、エンコーダー・デコーダーモデルが双方向のエンコーダーを使用するため、将来の文書のコンテキスト内で各文書を処理し、文書間の相対的な重要性の推定を改善する可能性があるため、コンテキストウィンドウをより良く使用すると仮定しています。
https://scrapbox.io/files/65abcba0d85e6300249613dd.png
4.2 クエリ認識のコンテキスト化の影響
私たちの多文書QAとキー値取得の実験では、クエリ（つまり、答えるべき質問や取得するべきキー）を処理するデータ（つまり、文書やキー値ペア）の後に配置しています。その結果、デコーダーのみのモデルは、クエリがプロンプトの最後にのみ表示され、デコーダーのみのモデルが各タイムステップで以前のトークンにのみ注意を払うことができるため、文書やキー値ペアを文脈化する際にクエリトークンに注意を払うことができません。対照的に、エンコーダー・デコーダーモデル（関連情報の位置の変更に対してより堅固であるように見える；§4.1）は、入力コンテキストを文脈化するために双方向のエンコーダーを使用します。この観察を利用して、データの前後にクエリを配置することで、文書（またはキー値ペア）のクエリ認識のコンテキスト化を可能にし、デコーダーのみのモデルを改善できるでしょうか？
我々は、クエリ認識のコンテキスト化がキー値取得タスクのパフォーマンスを劇的に改善することを発見しました。すべてのモデルは、75、140、および300のキー値ペア設定でほぼ完璧なパフォーマンスを達成します。例えば、クエリ認識のコンテキスト化を行ったGPT-3.5-Turbo（16K）は、300のキー値ペアで評価された場合に完璧なパフォーマンスを達成します。対照的に、クエリ認識のコンテキスト化を行わない場合、最悪のパフォーマンスは45.6%です（Figure 7）。キー値取得パフォーマンスに大きな影響を与えるにもかかわらず、クエリ認識のコンテキスト化は多文書質問応答タスクのパフォーマンス傾向に最小限の影響を与えます（Figure 9）。入力コンテキストの非常に始まりに関連情報がある場合にはパフォーマンスがわずかに向上しますが、他の設定ではパフォーマンスがわずかに低下します。
https://scrapbox.io/files/65abcc7532ae7b00237b21b5.png
私たちが評価したモデルはすべて、初期の事前学習の後、指示と応答のデータセットで監督されたファインチューニングを行います。タスク仕様や指示は通常、監督された指示ファインチューニングデータの入力コンテキストの最初に配置されます。これにより、指示ファインチューニングされた言語モデルは入力コンテキストの始めに重点を置く可能性があります。言語モデルが長い入力コンテキストをどのように使用するかに指示ファインチューニングがどのような影響を与えるかをよりよく理解するために、MPT-30B-Instructの多文書質問応答パフォーマンスを、そのベースモデル（つまり、指示ファインチューニング前）であるMPT-30Bと比較します。実験セットアップは§2と同じです。
Figure10は、MPT-30BとMPT-30B-Instructの多文書QAパフォーマンスを、入力コンテキスト内の関連情報の位置に基づいて比較しています。驚くべきことに、MPT-30BとMPT-30B-Instructの両方がU字型のパフォーマンス曲線を示し、関連情報がコンテキストの非常に始まりまたは非常に終わりにある場合に最も高いパフォーマンスを示しています。MPT-30B-Instructの絶対パフォーマンスはMPT-30Bより一様に高いですが、全体的なパフォーマンス傾向は似ています。また、指示ファインチューニングにより、ベースモデルの最良と最悪のケースのパフォーマンス差が約10%から約4%にわずかに減少することが観察されました。
https://scrapbox.io/files/65abccbfb9d19c0024513e31.png
これらの観測結果は、Instruction Tuningされていない言語モデルが最近のトークン（つまり、入力コンテキストの終わり）に偏っていることを発見した以前の研究を補完しています（Khandelwal et al., 2018; Press et al., 2021）。このリセンシーバイアスは、言語モデルが長距離情報から最小限の利益しか得られない連続テキストの次の単語予測を評価する際に過去の研究で観察されていました（Sun et al., 2021）。対照的に、私たちの結果は、指示フォーマットされたデータでプロンプトされた場合、言語モデルはより長い範囲の情報（つまり、入力コンテキストの始まり）を使用できることを示しています。私たちは、Instruction Tuningされていない言語モデルが、事前学習中に見たインターネットテキスト内の同様にフォーマットされたデータから、これらの長いコンテキストを使用する方法を学んだと仮定しています。例えば、StackOverflowの質問と回答などです。 追加のファインチューニングとモデルスケールの影響をよりよく理解するために、さまざまなサイズのLlama-2モデル（7B、13B、70B）を、追加の監視されたファインチューニングおよび人間のフィードバックからの強化学習を伴っておらずに実験しました（付録E参照）。U字型のパフォーマンス曲線は、十分に大きな言語モデル（追加のファインチューニングの有無にかかわらず）でのみ現れることがわかりました。7BのLlama-2モデルはリセンシーバイアスのみを持ち、13Bおよび70BモデルはU字型のパフォーマンス曲線を示します。さらに、13BのLlama-2監督されたファインチューニングと人間のフィードバックからの強化学習プロセスは、小さなモデル（MPT-30BとMPT-30B-Instructを比較したときに示される傾向に似ている）の位置バイアスをわずかに軽減しますが、大きなモデル（70B）の傾向には最小限の影響を与えます。
5 オープンドメインQAでのケーススタディを通じて、常にコンテキストが多い方が良いのか？
我々の結果は、言語モデルにより長い入力コンテキストをプロンプトすることはトレードオフであることを示しています。言語モデルにより多くの情報を提供することは、下流のタスクの実行に役立つかもしれませんが、モデルが推論する必要があるコンテンツの量も増加し、精度が低下する可能性があります。言語モデルが16Kトークンを取り込むことができても、16Kトークンのコンテキストを提供することが実際に有益であるかどうかは、追加されたコンテキストの限界価値とモデルが長い入力コンテキストを効果的に使用する能力に依存するため、最終的には下流タスク固有のものですが、我々は既存の言語モデルでこのトレードオフをより深く理解するために、NaturalQuestions-Openでのオープンドメイン質問応答を用いてケーススタディを実施します。
標準的なリトリバー・リーダーセットアップで言語モデルを使用します。リトリバーシステム（Contriever、MS-MARCOでファインチューニングされた）がNaturalQuestions-Openからの入力クエリを取り、最も関連性の高いk個のWikipedia文書を返します。言語モデルをこれらの取得された文書に基づいて条件付けするために、単にそれらをプロンプトに含めます。取得された文書の数kに関するリトリバーリコールとリーダーの精度（注釈付けされた回答のいずれかが予測された出力に現れるかどうか）を評価します。NaturalQuestions-Openのサブセットを使用します。ここでは、長い回答が段落であるもの（表やリストではないもの）を対象とします。Figure 11はリトリーバーリコールとオープンドメインQAの結果を示しています。リーダーモデルのパフォーマンスは、リトリーバーパフォーマンスが飽和するよりもずっと前に飽和することがわかります。これは、リーダーが追加のコンテキストを効果的に使用していないことを示しています。20以上の文書を取得することは、リーダーのパフォーマンスをわずかに改善するだけです（GPT-3.5-Turboで約1.5％、Claude-1.3で約1％）が、入力コンテキストの長さを大幅に増加させます（したがってレイテンシーとコストも増加）。これらの結果、およびモデルが入力コンテキストの最初または最後で情報を取得し、使用するのが得意であるという観察に基づいて、取得した文書の効果的な再ランキング（関連情報を入力コンテキストの始まりに近づける）またはランク付けされたリストの切り捨て（適切な場合に少ない文書を取得する；Arampatzis et al., 2009）が、言語モデルベースのリーダーが取得したコンテキストを使用する方法を改善するための有望な方向性であることを示唆しています。
https://scrapbox.io/files/65abd061a7ea2d0024902fd0.png
6 関連研究
6.1 長いコンテキストの言語モデル
コンテキストの長さに関してトランスフォーマーより安価なスケーリングを持つパフォーマントな言語モデルの設計に関する多くの以前の研究があります。多くの研究が、再帰（Dai et al., 2019）、計算的に簡単な近似への注意の分解（Beltagy et al., 2020; Zaheer et al., 2020）、または低ランク近似（Wang et al., 2020; Peng et al., 2021）などの注意変更を含むトランスフォーマーのバリアントを追求しています。Dao et al. (2022) は、注意深く作られたIO認識のCUDAカーネルによって、より速い正確な注意を提供します。別途、Attentionを完全に排除し、二次的なシーケンス長の複雑さを取り除く試みがあります。これは、しばしば畳み込みと/または線形RNNを通して行われます（例えば、RWKV（Peng, 2023）、S4（Gu et al., 2022）、Hyena（Poli et al., 2023）で）。多くの以前の努力は、長いコンテキストを処理する能力の代理として、多様なWebコーパスでの困惑度を評価しています。この研究は、長いコンテキストでの正確な知識アクセスが追加の課題であることを示しています。
6.2 言語モデルはコンテキストをどのように使用するのか？
Khandelwal et al. (2018) の先駆的な研究は、小さなLSTM言語モデルがより長期的なコンテキストの使用をますます粗くすることを示しました。Sankar et al. (2019) は対話モデルで同様の結果を見つけました。同じように、Daniluk et al. (2017) は、注意深いLSTM言語モデルが主に最近の歴史を使用することを発見しました。Petroni et al. (2020) は、情報検索システムからのコンテキストを事前訓練された言語モデルと組み合わせることで、教師なしの質問応答においてその可能性を初めて示しました。O'Connor and Andreas (2021) は、多くの情報破壊操作がTransformer LMsの予測にわずかな影響を与えることを発見しました。Krishna et al. (2022) は、適度なサイズのトランスフォーマー言語モデルにおける長いコンテキストの神経生成が、モデルが長いコンテキストに適切に条件付けされていないために劣化することを発見しました。最後に、長いコンテキストのモデルを研究するSun et al. (2021) は、長いコンテキストがわずかにいくつかのトークンの予測を改善することを発見しました。これは、Sharan et al. (2018) の理論と一致しています。彼らは、境界付き相互情報を持つシーケンス分布が、より長いコンテキストからの限界平均予測利益を必然的に導くことを示しました。Qin et al. (2023) は、効率的なトランスフォーマーが様々な長いコンテキストの下流NLPタスクでどのように機能するかを分析し、長いコンテキストのトランスフォーマーはリセンシーバイアスがあり、長距離のコンテキストを効果的に使用しないことを発見しました。
6.3 シリアルポジション効果
この作業で観察されるU字型の曲線は、シリアルポジション効果（Ebbinghaus, 1913; Murdock Jr, 1962）として知られる心理学での接続を持っています。これは、リストからの要素の自由連想リコールにおいて、人間はリストの最初と最後の要素を最もよく覚える傾向があるというものです。シリアルポジション効果は、人間が短期および長期記憶をどのように発達させるかを理解する上での役割を果たします。言語モデルでシリアルポジション効果に似た効果が観察されるのは、トランスフォーマー言語モデルの基盤となる自己注意機構が技術的にはコンテキストの任意のトークンを取り出す能力があるにもかかわらず、多少驚きかもしれません。
7 結論
我々は、一連の制御された実験を通じて、言語モデルが長い入力コンテキストをどのように使用するかを実証的に研究しました。言語モデルのパフォーマンスは、関連情報の位置を変更すると著しく低下し、モデルが長い入力コンテキスト内の情報に堅固にアクセスし、使用するのに苦労していることを示しています。特に、長い入力コンテキストの中間で情報を使用する必要がある場合、パフォーマンスはしばしば最も低くなります。我々は、(i)モデルアーキテクチャ、(ii)クエリ認識のコンテキスト化、および(iii)指示のファインチューニングの役割についての予備的な調査を行い、これらが言語モデルがコンテキストを使用する方法にどのように影響するかをより深く理解することを試みました。最後に、オープンドメイン質問応答の実用的なケーススタディを結論付けることで、言語モデルのリーダーのパフォーマンスがリトリーバーリコールよりもずっと前に飽和することがわかりました。我々の結果と分析は、言語モデルが入力コンテキストをどのように使用するかについての理解を深め、将来の長いコンテキストモデルに対する新しい評価プロトコルを提供します。